Just looking at GitHub Search there are over 100 consumers.

Just looking at GitHub Search there are over 100 consumers.

While we don't have strict rules when it comes to removing packages, I still don't think we should keep a package around that

• Didn't have any relevant upstream activity for more than 2 years
• Was explicitly marked as unmaintained
• Is potentially vulnerable (although to be fair, I haven't checked that the referenced vuln applies here)

Oh, I'm not against removing the package :) I'm just saying that this might affect a lot of users so linking a replacement or an alternative might be good idea in this case. RFC 180 describes a new process of removing packages which I think this PR complies with as most of the goals from it are not implemented yet.

New alternative popped up veeery recently https://github.com/dp0sk/crosspipe

Oh, I'm not against removing the package :) I'm just saying that this might affect a lot of users so linking a replacement or an alternative might be good idea in this case.

Agreed! Is there any alternative that's already packaged in nixpkgs? I'm not very familiar with helvum.

RFC 180 describes a new process of removing packages which I think this PR complies with as most of the goals from it are not implemented yet.

Thanks for pointing out this RFC, interesting read!

depends on the vulnerable shlex 1.2.0.

This is only a low severity CVE and from where should command injections come? From audio interface names? CVEs need to be assessed. Even a high or critical CVE in a package might only affect a part of it which is not even used or compiled by NixOS.

depends on the vulnerable shlex 1.2.0.

This is only a low severity CVE and from where should command injections come? From audio interface names? CVEs need to be assessed. Even a high or critical CVE in a package might only affect a part of it which is not even used or compiled by NixOS.

I intentionally did not assert that helvum was necessarily vulnerable.

"relies on vulnerable dependencies" means "there's something the upstream should do but they didn't", which is a proof of being unmaintained

It can, but it can also mean that dumb scanners are used. Please take a read in this issue from gosu tianon/gosu#104 which very often has to fight with this and I must agree with the maintainer, uses a lot of time for very questionable benefit.

This is just as a general note. helvum is unmaintained which is admitted by upstream but just because some dependency has some low CVE does not mean anything is unmaintained or vulnerable. I have to fight with this on the weekly at my day job and using tools like govulncheck makes the churn from infinite to doable. Not sure if rust has something similar but if it has we absolute should run that on the upstream source code and down rank any CVE to LOW or not applicable.

it's back to being maintained and has new releases, can we have it back?

Just revert this PR :)